Main Page>Table of contents>Overview of NetBIOS-over-TCP/IP>NetBIOS over TCP/IP>
Fortunately, the NetBIOS APIs can be used with any low-level transport protocol – such as TCP/IP. Unlike NetBIOS, TCP/IP is completely routable. Indeed, it is predominantly a point-to-point protocol that avoids broadcasting whenever possible. Thus, using TCP/IP as a way to move NetBIOS-based data is an attractive alternative to the flat and non-routable NetBEUI protocol that is the default in Windows for Workgroups.
Since NetBIOS uses names for addressing purposes while TCP/IP uses numbers, there must be some way to map the two so that both of them see what they expect. In order for NetBIOS-based applications to run over TCP/IP networks, the NetBIOS application must see names, and the IP protocol must see numbers, yet neither can see the other. A layer between the two must map NetBIOS names to IP addresses, and convert IP addresses back to NetBIOS names. This layer is known as NetBIOS-over-TCP/IP.
TCP/IP standards are defined by Requests for Comment, or RFCs. Anyone may submit an RFC for consideration as a standard (even you). Two such RFCs are 1001 and 1002, which define a standard method for running NetBIOS over TCP/IP. RFC 1001 defines a general overview, while RFC 1002 defines the details.
There are three types of NetBIOS nodes defined in these two RFCs. A b-node (broadcast node) is one that uses broadcasting to query nodes on the network for the owner of a NetBIOS name. A p-node (point-to-point node) uses directed calls to communicate with a known nameserver (not to be confused with DNS) for the IP address of a NetBIOS machine name. An m-node is a mixed node, one that uses broadcasted queries to find nodes, and failing that, queries a p-node nameserver for the address. Another type currently under review is an h-node, which reverses the m-node standard so that a directed query is executed first, and failing that, a broadcast is attempted. Remember that the node types apply only when a node is attempting to match an IP address to a NetBIOS node name. Once the device has discovered the IP address of the machine it's trying to communicate with, it no longer broadcasts information, but sends the IP traffic directly to the node associated with the NetBIOS name.
NBT can use a variety of mechanisms for name resolution. The simplest conceptual and practical method is to simply rely on the default of using broadcasts to locate network resources. This calls for the node to issue TCP/IP broadcasts for every NetBIOS query. Hopefully, the partner system is on your local network, and will see and respond to the broadcast. If you need to be able to configure more exacting name resolution patterns for more complex environments, then you will want to use on of the more powerful options available.
NBT can convert NetBIOS names to IP addresses in several ways. The one described above – broadcasting – hardly seems suitable in anything except the most simple networks. Another potential way to resolve the name is to pre-load the NBT name cache with an IP address. This is accomplished using a text file called LMHOSTS. Another option is to use Windows Internet Name Service (WINS) servers. A WINS server is essentially a p-node as described in RFCs 1001 and 1002, although as an implementation it is proprietary to Microsoft. You can also use your DNS servers as name servers, although this is very limited in functionality.
Assuming you have any of these name resolution options enabled on your Windows for Workgroups PC, the NBT name resolution applies the search in the following order of precedence until a name match is found.
If no match is found, a name-not-found error is returned to NetBIOS.